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Abstract 

Prolog  and  Lisp  benchmark  timings  are  compared  on  the  VAX  8600.  The  measured  Lisp-to 
Prolog  time  ratio  varies  between  0.143  and  2.83.  These  differences  between  Prolog  and  Lisp  perfor¬ 
mance  can  be  explained  by  studying  the  structure  of  the  benchmarks  and  the  language  implemen¬ 
tations.  Previous  authors  have  used  such  measurements  as  evidence  that  one  language  is  “better” 
than  the  other;  their  works  are  summarized.  The  issues  involved  in  comparing  two  languages  are 
treated,  as  well  as  the  assumptions  involved  in  interpreting  language  performance  data. 
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1  Introduction 


...a  very  well-known  professor  of  Computing  Science  made  the  statement  that  “Algol  60 
was  a  very  inefficient  language”,  while  what  he  really  meant  was  that,  with  the  equipment 
available  to  him,  he  and  his  people  had  not  been  able  to  implement  Algol  60  efficiently. 

(That  is  what  he  meant,  he  did  not  mean  to  say  it!) 

-  Edsger  W.  Dijkstra,  1974 

The  first  Prolog  compiler  was  presented  by  Warren  [15].  He  argued  that  his  Prolog  compiler 
produced  reasonably  efficient  code  by  comparing  timings  of  benchmarks  written  in  Prolog,  Lisp, 
and  Pop-2.  He  went  further  to  explain  why  some  benchmarks  ram  faster  in  Prolog  and  others  ran 
faster  in  Lisp  [14][15].  Warren’s  Prolog  compiler  used  an  intermediate  form  to  represent  program 
information  between  the  syntax-analyzer  and  code-generator.  This  intermediate  form  evolved  into 
what  is  known  as  the  Warren  Abstract  Machine  (WAM)  [16]. 

The  WAM  is  a  very  high-level  instruction  set;  early  Prolog  implementations  compiled  Prolog 
into  WAM  and  executed  the  WAM  instructions  on  a  software  simulator,  or  macroexpanded  the 
WAM  instructions  into  native  code.  More  recent  implementations  use  microcode  to  execute  WAM 
instructions  [2],  or  use  more  sophisticated  code-generators  to  produce  better  native  code.  These 
newer  implementations  appear  to  provide  a  significant  jump  in  performance.  It  is  reasonable  to 
wonder  how  advances  in  Prolog  implementation  technology  compare  to  similar  advances  for  Lisp, 
which  likewise  include  compiler  optimizations  and  microcode  or  other  forms  of  architectural  support. 

The  intent  of  this  paper  is  to  provide  a  framework  for  comparing  Lisp  and  Prolog  implementations 
both  now  and  in  the  future,  as  technologies  continue  to  advance.  Specifically  it  will 

•  Discuss  the  issues  involved  in  comparing  the  performance  of  two  languages. 

•  Summarize  previous  efforts. 

•  Present  a  number  of  benchmark  results,  and  explain  differences  in  performance. 

•  Discuss  the  interpretation  of  the  results  and  the  assumptions  involved. 

2  Comparing  Languages  X  &  Y 

Comparing  two  languages  is  difficult.  There  are  a  number  of  ambiguities  to  resolve,  in  terms  of 

1.  What  is  being  compared:  Programmability?  The  dollar  cost  of  the  compiler?  Execution 
speed?  Memory  requirements? 

2.  What  comparison  to  make:  Benchmark  tests?  Formal  analysis?  Many  important  aspects  of 
programming  languages  are  difficult  to  quantify. 

3.  How  to  interpret  the  results:  Are  the  results  absolute,  valid  across  all  programs'7  Do  they 
indicate  trends?  To  what  extent? 

On  the  most  abstract  level,  a  programming  language  can  be  characterized  as  a  mapping  of 
programs  to  the  functions  that  they  compute.  We  can  look  at  a  few  questions  from  this  perspective: 

1.  Program  size:  for  a  given  function  F,  which  language  maps  the  shortest  program  to  P7 

2.  Program  semantics:  languages  X  and  Y  map  program  P  to  functions  Fx  and  Fy ,  respectively. 
How  do  Fx  and  Fy  compare?  For  example,  one  might  be  an  extension  of  the  other. 

3.  Language  semantics:  in  an  enumeration  of  programs,  how  are  the  computable  functions  ordered 
under  each  language? 
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The  answers  to  these  questions  might  tell  us  whether  one  language  is  inherently  more  compact  or 
more  efficient  than  another.  Unfortunately  proofs  on  such  an  abstract  level  tend  only  to  work  only 
for  examples  too  simple  or  too  technical  to  be  of  any  interest. 

More  concrete  questions  of  immediate  interest  are  as  follows: 

1.  How  easy  is  the  language  to  program  in?  This  could  refer  to  programming  in  general,  construc¬ 
tion  of  a  particular  program,  or  programming  for  a  given  class  of  applications.  It  is  difficult 
to  measure  how  easy  a  language  is  to  learn  and  use.  Ease  of  programming  is  strongly  affected 
by  outside  factors,  such  as  the  available  documentation  and  the  programming  environment. 

2.  How  easy  is  the  language  to  implement  ?  The  implementation  includes  aspects  of  the  hardware, 
compiler,  and  runtime  system.  Some  languages  make  certain  optimizations  more  obvious.  An 
implementation  may  be  easy  because  it  performs  poorly  or  provides  little  debugging  informa¬ 
tion.  A  more  abstract  language  may  be  harder  to  implement. 

3.  How  efficiently  does  the  language  execute?  Efficiency  is  dependent  upon  the  implementation. 
A  highly  optimizing  compiler  may  speed  up  execution  time  at  the  expense  of  debug  time, 
making  the  system  harder  to  program.  One  may  wonder  how  efficiently  a  language  can  be 
implemented  given  the  hardware  resources  at  hand;  available  theoretical  approaches  appear  to 
provide  no  answer,  although  lowerbound  techniques  might  be  applied  in  specific  cases  [10]. 

Execution  efficiency  is  the  focus  of  this  report.  The  approach  taken  is  to  compare  execution 
times  of  benchmark  programs,  on  reasonably  fast  implementations  of  Lisp  and  Prolog.  There  are  a 
number  of  interrelated  considerations  affecting  the  performance  of  a  given  benchmark: 

1.  Use  of  an  Interpreter.  Programs  tend  to  run  5-10  times  more  slowly  interpreted  than  compiled. 
Interpreters  are  generally  designed  to  provide  a  high  degree  of  functionality  without  taking  a 
long  time  to  build;  program  execution  time  usually  suffers. 

2.  Efficiency  of  the  runtime  model.  An  interdependency  exists  between  the  representation  of  the 
program  state  at  runtime,  the  design  of  the  compiler  code-generator,  and  the  functionality  of 
the  hardware.  All  three  of  these  factors  affect  performance.  Design  of  the  runtime  system  cam 
make  up  for  apparent  inadequacies  in  the  hardware  functionality  (the  Smalltalk  SOAR  design, 
for  example  [13]). 

3.  Compiler  optimizations.  Optimizations  have  been  applied  to  “standard”  languages  like  Fortran 
for  quite  some  time.  For  newer  languages  like  Prolog  these  have  yet  to  be  explored.  Two  “good” 
compilers  for  the  same  language  and  machine  can  produce  object  code  differing  by  10-25%  in 
performance. 

4.  Architecture.  Both  the  speed  and  the  functionality  of  the  architecture  has  a  strong  impact  on 
performance.  The  raw  speed  of  the  Cray  computer,  for  example,  makes  it  one  of  the  fastest 
Lisp  machines. 

5.  “ Language  Power”.  Some  languages  might  not  be  able  to  express  algorithms  as  efficiently  as 
others,  beyond  the  capability  of  any  compiler  to  correct.  Nothing  concrete  is  known  about 
this,  though  some  hypotheses  have  been  made.  In  particular,  it  is  hypothesized  that  the  lack 
of  destructive  operations  in  Prolog  and  Pure  Lisp  is  a  liability  [10]. 

The  difference  in  execution  time  for  two  benchmarks  reflects  a  combination  of  these  factors.  The 
degree  to  which  each  consideration  affects  a  given  benchmark  can  be  determined  by  analyzing  the 
benchmark  and  its  steps  of  execution.  It  is  difficult,  however,  to  extrapolate  the  '‘general”  case  from 
specific  benchmarks;  such  results  are  always  questionable. 

Considerations  2  &  3  are  obviously  driven  by  language  semantics,  but  are  still  conditioned  by  the 
way  we  think  about  hardware  organization.  The  real  relationship  between  language  semantics  and 
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hardware  is  poorly  understood.  It  is  often  the  case  that  one  system  will  run  faster  for  some  programs 
and  more  slowly  for  others,  which  makes  it  difficult  to  decide  which  individual  design  decisions  are 
superior. 

3  A  Summary  of  Previous  Efforts 

By  now  we  have  seen  a  number  of  ambiguities  regarding  the  comparison  of  two  languages.  These 
ambiguities  can  potentially  cause  sloppy  analysis  of  results  and  erroneous  conclusions.  Some  previous 
language  comparison  efforts  are  described  here. 


3.1  Lisp/Prolog  Performance  Comparisons 

Gutierrez  compared  the  (DEC-10)  performance  of  a  theorem-prover  written  in  both  Lisp  and  Prolog, 
finding  the  Lisp  version  to  run  about  3  times  faster  than  the  Prolog  version  [4].  He  stated  that  the 
experiment  had  been  undertaken  to  “provide  a  basis  for  choosing  a  language  for  a  large  research 
project.”  A  general  factor  of  3  in  performance  would  probably  be  a  good  reason  to  favor  one  language 
over  another,  were  there  no  other  factors  involved  -  after  all,  why  not  use  assembly  language? 
Regardless,  O’Keefe  rebutted  this  [8],  rewriting  the  theorem-prover  to  be  faster  in  both  Lisp  and 
Prolog;  the  new  Prolog  version  generally  outran  the  new  Lisp  version  by  30-50%.  In  both  Gutierrez' 
and  O’Keefe’s  discussions  there  were  underlying  issues  which  were  not  treated: 

1.  Why  were  the  programs  structured  as  they  were?  To  be  most  efficient?  Most  natural?  The 
theorem-prover  written  by  Gutierrez  looks  reasonable  at  first  glance;  O’Keefe  showed  that  it 
handicapped  the  Prolog  implementation  several  ways.  This  argument  is  difficult  to  resolve: 
how  can  you  claim  to  have  made  the  “ultimate  rewrite”  of  a  program? 

2.  What  efficiency  issues  are  purely  implementation-dependent?  For  example,  O’Keefe  stated 
that  Prolog  is  faster  for  manipulating  records  and  Lisp  is  faster  for  manipulating  lists.  This 
is  purely  an  artifact  of  the  implementations;  the  runtime  representations  of  the  data  struc¬ 
tures  can  be  adjusted  if  they  penalize  performance  significantly.  Another  example  is  the 
“lazy  cons”  tail-recursion  optimization  that  Lisp  compilers  ignore  but  Prolog  compilers  do 
not;  this  optimization  is  regarded  as  an  important  efficiency  enhancement  in  Prolog,  whereas 
Lisp  implementors  don’t  consider  it  worth  the  effort.  The  Prolog  syntax  encourages  a  style  of 
programming  which  the  compiler  can  readily  optimize;  the  Lisp  syntax  does  not. 

3.  What  efficiency  issues  are  purely  language-dependent?  The  “inherent  efficiencies”  of  the  lan¬ 
guages  are  ostensibly  the  issue  in  these  papers,  but  it  is  not  clear  that  anything  other  than 
programming  style  and  implementation  tradeoffs  are  being  compared.  The  fundamental  dif¬ 
ference  in  language  semantics  suggest  that  some  inherent  difference  in  performance  must  exist 
[11],  but  as  yet  yields  no  insight  for  real  cases. 

These  issues  will  considered  in  our  later  discussion. 

Tick  [12]  made  a  more  analytic  comparison  using  the  Gabriel  benchmarks  [3]  Tak,  Boyer.  Deriv, 
and  Puzzle.  He  took  counts  of  procedure-calls,  memory  references,  and  instructions  executed,  and 
compared  raw  performance  on  a  Sun-3.  In  particular,  the  timing  ratios  of  Lisp-to-Prolog  were  01. 
0.59,  0.67,  and  3.47,  respectively.  (The  measurements  for  Puzzle  presented  later  show  Lisp  to  take 
about  50%  of  the  time  of  Prolog.  The  remaining  results  are  relatively  consistent).  Major  details 
of  the  compilers  and  architectures  which  would  tend  to  bias  the  results  were  made  explicit.  The 
Lisp  was  native-code  compiled  from  a  portable  intermediate  form,  and  the  Prolog  was  compiled  to 
an  intermediate  form  which  was  interpreted.  Neither  of  these  implementations  sounds  efficient:  any 
differences  in  performance  could  have  been  due  to  poor  expressiveness  of  the  the  Lisp  intermediate 
form,  or  the  interpretation  overhead  of  the  Prolog  intermediate  form. 
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Tick’s  conclusion  was  that  Prolog  has  a  greater  “semantic  content”  than  Lisp;  also  that  Lisp  is 
better  mapped  onto  current  machines  than  Prolog.  This  “semantic  content”  is  based  on  the  the 
ratio  of  instruction  to  data  transfer  rates  during  execution;  as  such  the  “semantic  content”  is  purely 
an  artifact  of  the  Prolog  and  Lisp  runtime  models.  The  superior  mapping  of  Lisp  onto  the  hardware 
may  be  true  for  those  implementations;  very  likely  we  will  find  better  ways  to  implement  Prolog  in 
the  future. 

3.2  Benchmark  Suites 

Gabriel  presented  a  “standard”  suite  of  Lisp  benchmarks  and  compared  the  results  for  a  large  number 
of  implementations  [3].  This  caused  a  stir  in  the  Lisp  community  not  only  because  it  gave  customers 
a  comparison  upon  which  to  choose,  but  because  it  forced  Implementors  to  realize  the  effects  of  their 
design  decisions.  A  suite  of  Prolog  benchmarks  was  developed  by  Wilk  [17].  Okuno  [9]  presented  the 
results  for  a  combination  of  Lisp  and  Prolog  benchmarks;  only  a  few  of  the  benchmarks  were  written 
in  both  Lisp  and  Prolog.  Additional  benchmarks  for  Prolog  continue  to  appear;  a  particularly 
“meaty”  collection  was  presented  recently  [6]. 

Most  of  the  early  Prolog  and  Lisp/Prolog  benchmarks  fall  into  the  category  of  diagnostic  or 
microscopic  benchmarks,  as  they  measure  specific  parameters  such  as  the  speed  of  procedure-call  or 
list  operations.  Diagnostic  benchmarks  are  perhaps  more  useful  for  tuning  an  implementation,  as 
they  identify  potential  performance  bottlenecks.  The  performance  results  for  diagnostic  benchmarks 
tend  to  be  easier  to  interpret,  since  the  benchmarks  are  short  or  spend  most  of  their  execution  time 
within  small  sections  of  code.  The  alternative  is  application  or  macroscopic  benchmarks,  such  as  the 
theorem-provers  of  Gutierrez  and  O’Keefe.  Most  of  the  Gabriel  suite  falls  into  this  category;  a  few 
of  these  have  been  converted  to  Prolog,  the  results  of  which  will  be  presented  later. 

3.3  Other  Work 

McDermott  [7]  discussed  the  pros  and  cons  of  the  Prolog  language  from  the  perspective  of  the 
contemporary  AI  community,  focusing  on  functionality  aspects. 

An  interesting  experiment  was  reported  in  [5],  where  programmers  were  timed  while  they  coded 
a  set  of  Al-related  problems  into  Ada,  Lisp,  and  Prolog.  Their  performance  for  Lisp  and  Prolog  were 
roughly  comparable  up  to  the  debugging  stage,  where  the  Prolog  programmers  were  bogged  down. 
The  Ada  programmers  performed  worst  or  near- worst  all  around.  The  results  of  such  experiments 
are  all  too  fallible,  but  are  interesting  to  consider. 

4  The  Benchmarks  &  Measurements 

In  this  section  we  measure  the  performance  of  Quintus  Prolog  2.0  and  Franz  Lisp  Opus  43.1  running 
on  a  VAX  8600  (“Vangogh”  at  UC  Berkeley).  Seven  benchmarks  are  used,  named  Nreverse,  Tak. 
Boyer,  Browse,  Frpoly,  Prover,  and  Puzzle.  The  numbers  are  summarized  below  in  table  1.  Each 
benchmark  was  run  5  times,  and  the  variation  in  timings  was  less  than  10%.  The  entries  for  garbage- 
collection  time  were  omitted  when  the  value  was  zero  (the  Prolog  system  supports  garbage-collection, 
but  didn’t  perform  any  for  these  cases).  “CPU”  is  the  total  execution  time  minus  “GC”,  which  is  the 
time  spent  in  garbage-collection.  Franz  Lisp  “locaiP  declarations  were  used  for  fast  function-call. 
Vectors  were  used  in  the  Puzzle  benchmark.  “Fixnum"  operators  were  used  in  most  cases,  which 
assume  the  results  of  integer  operations  stay  within  a  fixed  range. 
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Table  1  -  Benchmark  Timings  for  Lisp  and  Prolog  (in  seconds) 

Benchmark 

Case 

Prolog 

CPU 

L 

CPU 

sp 

GC 

N  reverse 

0.0134 

0.015 

Tak 

2.45 

0.35 

14.75 

25.28 

B  rowsel 

18.84 

53.33 

Frpoly 

1 

0.10 

0.067 

2 

1.24 

1.48 

3 

9.22 

Prover 

1 

0.034 

0.033 

2 

0.083 

3 

0.10 

0.05 

4 

0.083 

0.033 

5 

0.10 

0.083 

6 

0.18 

0.13 

7 

0.20 

0.13 

8 

0.35 

0.35 

0.25 

9 

0.40 

0.32 

10 

0.70 

0.63 

Puzzle 

10.34 

5.04 

1 12. 18  seconds  CPU/14.29  seconds  GC  for  8600  Common  Lisp  [3]. 

138.69  seconds  CPU  for  8600  Common  Lisp  [3]. 

The  benchmarks  are  listed  in  Prolog  in  the  appendix;  the  Lisp  versions  are  in  Gabriel  [3],  with 
the  exception  of  Prover  and  Nreverse  whose  Lisp  translations  are  also  included  in  the  appendix.  We 
will  examine  the  benchmarks  one  by  one  and  try  to  explain  the  timing  difference. 

Nreverse 

The  Nreverse  benchmark  is  a  test  of  the  so-called  lazy  cons  tail-recursion  optimization  of  Prolog. 
The  clause 


concatenate ( [XI H] ,L2 , CX I L3] )  concatenateCLl ,L2 ,L3) . 

when  used  with  instantiated  first  and  second  arguments,  will  allocate  a  list  cell  for  the  third  argu¬ 
ment;  the  recursive  call  (destructively)  “fills  in'’  L3.  This  tail-recursive  clause  is  compiled  into  an 
iterative  loop  by  all  WAM-based  Prolog  compilers. 

The  Lisp  form  of  that  same  line  is 

(cons  (car  LI)  (concatenate  (cdr  LI)  L2)) 

which  defers  setting  up  the  list  cell  until  after  the  recursive  call  to  concatenate.  Rearranging  this 
form  to  be  tail-recursive  gives 

(setq  L  (cons  (car  LI)  nil)) 

(dconcatenate  L  (cdr  LI)  L2) 
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where  dconcatenate  destructively  attaches  the  result  onto  L.  Tail-recursion  optimization  is  now  ap¬ 
plicable.  To  do  this  automatically  on  the  first  form  would  require  analysis  techniques  which  are 
beyond  any  existing  Lisp  compiler.  Programming  in  the  style  of  the  second  form  is  awkward,  so 
Lisp  does  appear  to  be  at  a  disadvantage  here. 

The  Prolog  version  of  N reverse  runs  about  10%  faster  than  the  Lisp  version,  which  I  (following 
the  lead  of  Warren  [14])  would  attribute  to  the  removal  of  tail-recursive  procedure-call  overhead. 

Tak 

The  Tak  benchmark,  on  the  other  hand,  favors  the  Lisp  system  over  the  Prolog  system.  This  is 
a  quadruply-recursive  program  which  performs  integer  arithmetic.  WAM-based  Prolog  implemen¬ 
tations  are  at  a  disadvantage  here;  the  flow  of  control  is  strictly  deterministic  by  the  semantics  of 
the  arithmetic  operations,  but  work  is  nonetheless  performed  to  set  up  choice-points  and  maintain 
backtracking  information.  Data  flow  analysis  would  be  sufficient  to  correct  this,  but  it  is  not  clear 
that  Prolog  programs  would  generally  benefit  from  this  optimization. 

Boyer 

Profiling  the  Prolog  version  of  the  Boyer  benchmark  shows  that  roughly  90%  of  the  executed  WAM 
instructions  were  in  the  routines 


rewrite (Atom .Atom)  : - 

atomic (Atom) , ! . 
rewrite(Old.Iew) 

functor(01d,F.*) , 
functor(Mid.F.I) , 
rewrite_args(I,01d,Hid) , 
(  equal(Mid.Kext) , 
rewrite (lext , Hew) 

;  Hew=Mid 

).!• 


rewrite„args(0,_,_) 

rewrite_args(I,01d,Mid) 

arg ( I , Old , OldArg) , 
arg(I,Mid,MidArg) , 
rewrite(OldArg.MidArg) , 

■1  is  1-1, 

rewrite_args(51 ,01d, Mid) . 


The  results  will  be  very  sensitive  to  how  this  portion  executes.  The  Lisp  version  was  not  profiled, 
but  the  corresponding  routines  are  considerably  more  complicated: 

(defun  rewrite  (term) 

(cond  ((atom  term)  term) 

(t  (rewrite-with-Iemmas  (cons  (car  term) 

(rewrite-axgs  (cdr  term))) 

(get  (car  term)  (quote  lemmas)))))) 
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(daiun  rawrite-args  (1st) 

(cond  ((null  1st)  nil) 

(t  (cons  (rewrite  (ear  1st)) 

(rewrite-args  (cdr  1st)))))) 

(deiun  rawrita-with-lemmas  (tera  1st) 

(cond  ((null  1st)  term) 

((one-way-uniiy  term  (cadr  (car  1st))) 

(rewrite  (apply-subst  uniiy-subst  (caddr  (car  1st))))) 

(t  (rewrite-witb-lemmas  term  (cdr  1st))))) 

(deiun  apply-subst  (alist  term) 

(cond  ((atom  term) 

(cond  ((setq  temp-temp  (assq  term  alist)) 

(cdr  temp-temp)) 

(t  term))) 

(t  (cons  (car  term)  (apply-subst-lst  alist  (cdr  term)))))) 

(deiun  apply-subst-lst  (alist  1st) 

(cond  ((null  1st)  nil) 

(t  (cons  (apply-subst  alist  (car  1st)) 

(apply-subst-lst  alist  (cdr  1st)))))) 

(deiun  one-way-uniiy  (terml  term2) 

(progn  (setq  uniiy-subst  nil) 

(one-way-uniiyl  terml  term2))) 

(deiun  one-way-uniiyl  (terml  term2) 

(cond  ((atom  term2) 

(cond  ((setq  temp-temp  (assq  term2  uniiy-subst)) 

(equal  terml  (cdr  temp-temp))) 

(t  (setq  uniiy-subst  (cons  (cons  term2  terml) 

uniiy-subst) ) 

t))) 

((atom  terml)  nil) 

((eq  (car  terml)  (car  term2)) 

(one-way-uniiyl-lst  (cdr  terml)  (cdr  term2))) 

(t  nil))) 

(deiun  one-way-uniiyl-lst  (lstl  lst2) 

(cond  ((null  lstl)  t) 

((one-way-uniiyl  (car  lstl)  (car  lst2)) 

(one-way-uniiyl-lst  (cdr  lstl)  (cdr  lst2))) 

(t  nil))) 

As  McDermott  pointed  out  [7],  Prolog’s  real  strength  lies  in  the  ability  to  describe  pattern-matching 
processes  in  a  concise  way.  The  Lisp  version  of  the  benchmark  has  to  define  its  own  pattern- 
matcher  which  explicitly  decomposes  argument  data-structures  and  matches  basic  patterns.  This 
is  done  implicitly  by  the  unification  routines  in  the  Prolog  runtime  system.  The  Lisp  version  pays 


the  overhead  of  the  procedure-calls  in  the  unification  process,  making  it  considerably  slower.  The 
Prolog  version  permits  optimization  of  the  tail- recursive  call  in  rewrite- args.  The  Prolog  version  also 
represents  data  differently,  using  functors  in  some  places  rather  than  lists.  Nonetheless,  the  8600 
Common  Lisp  results  reported  in  [3]  are  more  competitive  with  the  Prolog  measurements  presented 
here. 

Browse 

The  main  routine  match  of  the  Browse  benchmark  consumes  >  90%  of  the  execution  time.  In  the 
Lisp  version  it  is  52  lines  long;  in  the  Prolog  version  it  is  10  lines  long.  There  are  a  number  of  places 
where  operations  are  repeated,  such  as  (car  pat),  or  dereferences  are  repeated  in  taking  the  car 
and  cdr  of  the  same  variable.  Such  repeated  work  can  be  eliminated  by  the  compiler  if  it  confirms 
that  there  are  no  side-effects  tampering  with  the  intermediate  pointers,  so  these  pointers  can  be 
saved  rather  than  recomputed.  As  with  the  “lazy-cons”,  such  an  optimization  may  not  be  generally 
useful. 

The  program  can  be  rewritten  to  use  temporary  variables  to  hold  intermediate  values.  The 
compiler  must  then  be  smart  enough  store  these  variables  in  registers  rather  than  in  memory,  where 
the  dereferencing  would  have  to  occur  anyway.  Registers  are  generally  not  used  in  the  Franz  Lisp 
implementation. 

Frpoly 

The  Frpoly  benchmark  was  designed  to  mimic  computations  in  the  Macsyma  system.  As  a  Lisp 
benchmark  it  would  give  an  indication  of  Macsyma  performance  on  a  particular  Lisp  system.  Frpoly 
symbolically  expands  the  expression  (x  +  y  +  r  + 1)”  for  n  =  5, 10, 15,  where  intermediate  expressions 
maintain  a  canonical  form  at  certain  steps  of  the  computation. 

The  Lisp  version  uses  some  messy  data-structure  manipulations,  drawn  from  the  Macsyma 
polynomial-manipulation  package.  Destructive  operations  are  used,  presumably  to  save  time  and 
reduce  the  number  of  scratch  list-cells  used.  These  destructive  operations  did  not  translate  to  Pro¬ 
log,  so  a  simpler  but  “less  efficient”  scheme  is  used.  The  Lisp  version  uses  a  routine  to  explicitly 
put  expressions  into  canonical  form,  as  is  done  in  Macsyma,  while  the  Prolog  version  maintains  the 
canonical  form  all  along.  Since  the  algorithmic  structure  is  not  the  same  for  both  cases  we  cannot 
really  judge  the  languages  by  this  benchmark. 

P rover 

The  Prover  benchmark  from  O’Keefe  does  not  appear  to  favor  or  penalize  either  language.  The 
program  structures  are  virtually  identical,  and  neither  relies  on  any  “unpopular”  language  features 
which  may  not  be  well-implemented.  In  O’Keefe’s  original  paper  the  Prolog  implementation  tended 
to  be  a  bit  faster;  in  these  tests  the  Lisp  implementation  tends  to  be  faster. 

Puzzle 

The  Puzzle  benchmark  finds  ways  of  packing  pieces  in  a  5x5x5  cube  by  trying  all  possible  combi¬ 
nations.  The  Lisp  version  uses  an  array  to  represent  the  arrangements.  Failed  combinations  are 
undone  and  retried  with  different  choices. 

The  Prolog  coding  uses  backtracking  to  undo  failed  combinations:  in  order  to  keep  track  of 
the  number  of  combinations  attempted,  a  global  variable  is  maintained  using  the  set/ access  or 
assert/retract  operations.  In  the  Quintus  implementation  a  full  assert/retract  is  used,  which  involves 
a  substantial  runtime  overhead.  The  Prolog  coding  has  a  further  disadvantage  of  using  lists  instead 
of  arrays,  which  imply  more  sequential  accesses  to  data. 
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4.1  A  Note  on  the  Code 


Looking  at  the  output  of  the  Lisp  compiler  shows  that  there  is  room  for  further  improvement.  The 
following  sequence  is  from  apply-subst  in  the  inner-loop  part  of  the  Boyer  benchmark: 


L18: 


subl2 

$8,r8 

aovl 

rO.rO 

movl 

28(r8) ,rl 

aovl 

4(rl) ,rl 

aovl 

rO.O(rl) 

jeql 

LIS 

aovl 

28(r8) ,rl 

aovl 

*4(rl) ,r0 

aovl 

rO.rO  • 

aovl 

0(r0) .rO 

jbr 

L14 

The  movl  rO.rO  operations  are  redundant,  as  well  as  the  second  movi  28(r8),rl  operation:  overall 
there  is  a  lot  of  stacking  and  unstacking  of  variables,  as  registers  are  not  used  to  transmit  parameters 
in  procedure-calls.  Unfortunately  the  Prolog  compiler  does  not  produce  symbolic  output  for  us  to 
examine.  Very  likely  both  compilers  couid  use  additional  optimizations.... 

5  Interpretations 

Ideally  this  paper  would  compare  the  usefulness,  or  at  least  the  relative  performance  of  Prolog 
and  Lisp,  as  might  be  expressed  by  the  diagram  on  the  left.  As  outlined  in  section  2,  there  are  a 
number  of  complicating  issues  which  cannot  be  readily  resolved.  We  are  instead  forced  to  make  a 
more  pragmatic  treatment  -  evaluating  a  measure  that  is  easy  to  quantify  (VAX  performance)  on  a 
domain  of  programs  we  can  deal  with  (benchmark  programs).  This  pragmatic  comparison  is  better 
expressed  by  the  diagram  on  the  right: 


Problem 

Domain 


'Natural* 

Lisp 

Programs 


'Natural* 

Prolog 

Programs 


Timing 

Companson 


Existing 

Programs 


Codings 

I 

Prolog 

Rewntes 


Contnved 

Problems 


Timings 
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The  concepts  on  the  right  only  crudely  approximate  the  concepts  on  the  left.  Rather  than  an  AI 
problem  domain,  we  have  algorithms  scavenged  from  existing  programs  with  a  few  contrived  ones 
thrown  in,  Rather  than  natural  Lisp  and  Prolog  codings  we  have  direct  Lisp  and  Prolog  rewrites  of 
these  algorithms.  For  those  we  have  specific  timings. 

The  natural  program  style  have  may  have  a  significant  bearing  on  the  inherent  usefulness  of  a 
language.  Language  X  might  efficiently  express  function  F,  but  be  unrepresentative  because  real 
programmers  are  unable  to  utilize  X  so  effectively.  The  naturalness  of  a  piece  of  code  depends  on 
the  experience  of  the  programmer  writing  (or  critiquing)  it,  the  aesthetic  notions  of  programming 
style,  etc.  and  is  difficult  to  measure.  The  benchmarks  in  this  study  are  small  enough  that  there 
is  little  freedom  of  choice  in  rewriting  them.  Thus  any  distinctions  in  “natural”  programming  style 
between  Lisp  and  Prolog  would  not  be  very  pronounced  in  these  tests. 

Do  these  results  have  any  bearing  on  the  ideal  comparison?  We  have  already  exposed  issues 
involved  in  interpreting  these  results.  If  we  read  the  results  of  our  pragmatic  comparison  ver  batim 
it  appears  that  the  Prolog  and  Lisp  implementations  are  roughly  competitive,  with  Lisp  slightly 
favored.  In  the  extreme  cases,  Prolog  was  7x  slower  than  Lisp  (Tak),  and  Lisp  was  2.8x  slower  than 
Prolog  (Browse).  Among  the  larger  benchmarks,  Prolog  was  only  2.5x  slower  than  Lisp  ( Prover , 
case  #4).  Even  among  the  results  for  Prover  there  was  a  substantial  variation,  with  Lisp  being  equal 
to  Prolog  in  case  #8  and  1.7x  slower  if  we  include  GC  time. 

Studies  like  this  typically  assume  that  the  performance  ratio  will  stay  the  same  as  implemen¬ 
tations  improve.  Otherwise  measurements  made  on  interpreters  would  be  uninteresting  -  if  the 
interpreter  for  language  X  loses  against  the  interpreter  for  language  Y,  we  might  conclude  that  Y 
was  inherently  faster  than  X.  But  we  can  rest  assured  that  if  we  compile  language  X,  it  will  run 
faster  than  the  interpreter  for  language  Y.  So  until  we  compile  language  Y  as  well,  X  will  appear 
faster.  What  happens  when  we  compile  language  Y ?  The  comparison  usually  changes  as  the  imple¬ 
mentations  improve.  Extrapolating  the  performance  ratio  from  one  generation  of  implementations 
to  another  will  not  work,  any  more  than  does  extrapolating  the  performance  of  one  benchmark  to  a 
suite  of  benchmarks.  A  prime  example  is  in  comparing  Gutierrez’s  [4]  results  to  O’Keffe’s  [8],  and 
O’Keefe’s  results  to  the  ones  here  -  clearly  the  performance  ratio  was  not  preserved! 

Further  improvement  is  likely  to  continue.  Examination  of  the  Franz  Lisp  object  files  shows 
room  for  further  optimizations.  There  are  a  number  of  obvious,  unexploited  high-level  optimization 
techniques  available  for  both  Lisp  and  Prolog.  Already  there  are  faster  Prolog  systems  in  the  works. 

As  implementations  get  faster,  more  and  more  deficiencies  in  the  system  design  will  have  to 
have  been  “ironed  out”  (i.e.  poor  garbage-collection  mechanisms,  inefficient  register  usage  by  the 
compiler,  etc.).  If  there  is  such  a  thing  as  “inherent  efficiency”  of  a  programming  language,  we 
should  approach  this  limit  as  the  efficiency  of  existing  implementations  improves. 

However,  we  need  to  distinguish  between  improvements  which  reflect  a  speedup  for  all  or  “most” 
programs,  and  those  which  only  apply  to  a  given  benchmark  or  small  set  of  benchmarks.  Comparing 
results  for  the  Tak  benchmark,  for  example,  it  appears  that  Prolog  could  greatly  benefit  from 
compiletime  determinacy  analysis.  But  this  is  not  so  dear  from  the  other  benchmarks;  Tak  is 
unusually  sensitive  to  determinacy  optimization. 

In  fact  we  could  make  optimizations  even  more  benchmark-specific  by  building  a  system  with 
lookup- tables,  which  identify  a  given  benchmark  and  print  its  results  without  actually  executing  it. 
The  “fastest”  system  for  executing  a  given  benchmark  would  have  to  use  precisely  this  approach! 
As  we  consider  “increasingly  efficient”  systems  we  must  keep  this  point  in  mind,  whether  our  “in¬ 
creasingly  efficient”  implementations  are  evolving  toward  the  “generally  most  efficient”  system  or 
merely  one  with  a  large  lookup  table.  The  successive  improvements  in  the  implementations  should 
be  made  with  generality  in  mind. 

In  my  opinion,  for  sufficiently  well-implemented  Lisps  and  Prologs  there  will  always  be  programs 
running  faster  in  one  than  the  other  if  translated  m  a  “natural”  way.  This  discrepancy  can  be 
patched  one  way  or  the  other  by  rewriting  the  benchmark,  modifying  the  system,  or  both,  but  the 
benchmark  programs  end  up  having  a  contrived  look  or  the  system  will  become  optimized  for  highly 
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unlikely  cases. 
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Appendix:  the  Benchmarks 

l.a.  Prolog  N reverse 


•a 

I. 

7. 

7.7. 


7.7. 

Prolog  version  of  "nreverse  list30"  benchmark,  7. 

from  Warren's  thesis.  7. 

7.7. 


Iist30( [1,2 .3, 4. 5, 6 ,7 .8, 9 ,10, 11, 12. 13, 14. 15, IS, 17, 18. 19, 20, 21. 22, 23, 24, 25. 26, 27, 28, 29 ,30* 


nreverse( [XILO] ,L)  nreverse(LO.Ll) ,  concatenate(Ll , [X] ,L) . 
nreverseC  □  ,  □  ) . 


concatenate( [X I Ll] ,L2 , [X I L3] )  concatenate(Ll ,L2 ,L3) . 
coneat enate(  □  ,L,L) . 

main  statistics, 
list30(L30) , 
nreverse(L30,X) , 
statistics, 
write(X) . 
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e 


l.b.  Lisp  Nreverse 


Warren  benchmark  "nreverse  list30",  lor  comparison 
of  various  LISPs  and  PROLOGS. 


(delun  nreverse  (1) 

(cond  ((null  1)  nil) 

(t  (concatenate  (nreverse  (cdr  1)) 

(cons  (car  1)  nil))))) 

(defun  concatenate  (11  12) 

(cond  ((null  11)  12) 

(t  (cons  (car  11)  (concatenate  (cdr  11)  12))))) 


(defun  test  () 

(prog  (H  I  J  K  list30) 

(setq  list30  ■ (1  2  3  4  S  «  7  3  9  10  11  12  13  14  15  16  17  18  19  20  21 
22  23  24  25  26  27  28  29  30)) 

(do  ((I  0  (1+  I))) 

((>  I  100)) 

(nreverse  list30)))) 


(defun  doit  () 

(prog  (X  Y) 

(setq  X  (ptime)) 

(test) 

(setq  Y  (ptime)) 

(return  (cons  (-  (car  Y)  (car  X)) 

(-  (cdr  Y)  (cdr  X)))))) 
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2.  Prolog  Tak 


•/./*  Copyright  Hsrvs’  Touati,  Aquarius  Projsct,  UC  BsrXeley  */ 

main  statistics(runtias,_) , 
taX( 18 ,  12,  6,  X). 
statistics(runtim«, [_,T] ) , 
writs(T) ,  al, 
srits(X) ,  al. 

tai(X,Y,Z,A) 

X  =<  Y,  ! , 

Z  =  A. 

taX(X,Y,Z,A) 

XI  is  X  -  1, 
taX(Xl ,Y,Z,A1) , 

Y1  is  Y  -  1, 
tak(Yl ,Z,X,A2) , 

Z1  is  Z  -  1. 
takCZl ,X,Y,A3) , 
tak(Al,A2,A3,A). 
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3.  Prolog  Boyer 


'/./•  Copyright  Herve’  Touati,  Aquarius  Project,  UC  Berkeley  */ 

X 
X 
X 
X 
X 
X 
X 
X 

main  statistics, 

rff (I) .tautology(X) , 
statistics . 

wff (implies(and(implies(X, Y) , 

and ( implies (Y, 2) , 

and( implies (Z.U) , 

implies(U.W))))  , 
implies (I, W) ) ) 

X  *  f (plus(plus(a,b) ,plus(c,rero))) , 

Y  *  f (times(times(a,b) ,plus(c,d))> , 

Z  a  f(reverse(append(append(a,b) ,  □))) , 

U  ■  equal (plus (a. b) .differenced, y)) , 

W  *  lessp(remainder(a,b) ,member(a,length(b) ) ) . 

tautology (Vff) 

write( 'rewriting. . . ’) ,nl, 
rewrite(Vff .lewWff) , 
write( 'proving. . . ’ ) ,al, 
tautologydewWff 

tautology (Wff, Tlist, Flist) 

(truepOJff  .Tlist)  ->  true 
;f alsep(Wff .Flist)  ->  fail 
; Wff  =  ii (If .Then, Else)  -> 

(truepClf .Tlist)  ->  tautology(Then,Tlist , Flist) 

;falsep(If .Flist)  ->  tautology (Else , Tlist , Flist) 

;  tautology  (Then,  [If  I  Tlist]  ,  Flist) ,  7,  both  must  hold 

tautology (Else, Tlist, [If IFlist]) 

) 

).  !  . 

rewr ite(Atom , Atom) 

atomic( Atom) , ! . 
raurite(Qld,jreu) 


Benchmark  Program  -  Boyer 
Lisp  vs .  Prolog  Study 

Copyright  by  Evan  Tick 
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functor ( Old, F,S) , 
functor (Mid ,F,H) , 
resrite.argsd.Old.Mid) , 

(  equal(Mid,Next) ,  '/.  should  be  ->,  but  is  compiler  smart  enough? 

rewritedext.Nes)  to  generate  cut  for  ->? 

;  Hes=Mid 

).!- 

rewrite_2Lrgs(0,_,_)  !. 
rewrite.argsd.Qld.Mid) 

arg(I,01d,01dArg), 
arg(S,Mid,MidArg), 
resrrite(01dArg,MidArg) , 

SI  is  B-l, 

reHrrite_args(Nl,01d,Mid)  . 
truep(t,_)  ! . 

truep(Wff .Tlist)  aeaberCWff .Tlist) . 
falsep(f,_)  !. 

f alsep(Uff .Flist)  meaber(Wff .Flist) . 

member  ( X,  [X  I  _]  )  !. 

member ( X, [_ IT] )  member (X ,T) . 


equal(  and(P,Q),  %  106  rules 

if (P,if (Q,t,f) ,f) 

). 

equal(  app end ( append (X,Y) ,Z) , 
append(X , append( Y , Z) ) 

)• 

equal(  assignment (X ,append(A ,B) ) , 
if (assignedp(X.A) , 
assignment (X, A) , 
assignment (X , B ) ) 

). 

equal (  assume. false(Var , Alist) , 
cons  (cons  (Vau:  ,f)  .Alist) 

). 

equal(  as sume .true (Var , Alist ) , 
cons (cons (Var.t) , Alist) 

). 

equal(  boolean(X) , 

or ( equal (X,t) , equal (X,f )) 

). 

equal(  car (gopher(X) ) , 
if (listp(X) , 
car (flatten(X) ) , 
zero) 

). 
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equalC  compile (Form) , 

reverse(codegen(optimize(Form) ,  □)) 

). 

equal(  count_list(Z,sort_lp(X,Y)) , 
plus(count_list(Z,X) , 
count_list(Z,Y)) 

). 

equal(  countps_(L,Pred) , 

countps_loop(L,Pred,zero) 

). 

equal (  dif ierence( A , B) , 

C 

)  differenee(A,B,C) . 
equal(  divides(X.Y) , 

zerop(remainder( Y , X) ) 

). 

equalC  dsort(X) , 

•ort2(X) 

). 

equalC  eqp(X,Y), 

equal (fix(X) ,fix(Y)) 

). 

equalC  equal(A,B), 

C 

)  eq(A , B , C)  . 

equalC  evenl(X), 

ifCzerop(X) ,t,odd(decr(I))) 

). 

equalC  exec (append(X ,Y) , Pda ,Envrn) , 

execCY.execCX.Pda.Envra) ,Envrn) 

). 

equalC  exp(A.B), 

C 

)  exp(A,B,C). 

equalC  lact_(I), 

fact_loop(I , 1) 

). 

equalC  faleify(X) , 

falsifyl (normalize (X) ,  □  ) 

). 

equalC  fix(X) , 

if (numberp(X) ,X,zero) 

). 

equalC  flatten(cdr(gopher (X) ) ) , 
if (listp(X) , 

cdr (f latten(X) ) , 
consCzero ,  □  ) ) 

). 

equalC  gcd(A.B), 

C 

)  gcdCA.B.C). 
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equal ( 
equal ( 
equal ( 
equal ( 
equal ( 
equal ( 
equal ( 
equal ( 


equal ( 
equal ( 
equal ( 
equal ( 
equal ( 
equal ( 
equal ( 


equal ( 


get(J,set(I,Val,Mem)) , 
ii(eqp(J,I) ,Val,get(J,Mem)) 

). 

greatereqp(X.Y) , 
not(lessp(X, Y) ) 

). 

greatereqprCX , Y) , 
not(lessp(X, Y) ) 

)• 

greaterp(X.Y) . 
lessp(Y.X) 

). 

ifCif(A.S.C) ,D.E) , 
if(A.if(B,D,E),if(C,D,E)) 

). 

iff(X.Y), 

and( implies (X , Y) , implies (Y ,X) ) 

). 

implies (P ,Q) , 
if(P,if(Q,t,f) ,t) 

). 

last (appendC A , B) ) , 
ifClistp(B) , 
last(B), 
if (listp(A) , 

cons(car(last(A))) , 

B)) 

). 

length(A) , 

B 

)  mylengtli(A,B)  . 

lesseqpCX, Y) , 
not (lesspCY , X) ) 

). 

lessp(A.B) , 

C 

)  lessp(A,B,C) . 

listpCgopher(X)) , 
listp(X) 

). 

mc_flatten(X,Y) , 
appendCflatten(X) ,Y) 

). 

meaning(A,B) , 

C 

)  meaning(A ,B , C) . 

member(A , B) , 

C 

)  mymember(A,B ,C) . 

not(P) , 

if(P.f.t) 
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). 

equal C  nth(A,B), 

C 

)  nth(A.B.C). 

equal (  numberp(greatest_factor(X,Y)) , 

not(and(or(zerop(Y) ,equal(Y,l)) , 
not (numberp ( X ) ) ) ) 

). 

equal (  or(P,Q), 

). 

equal(  plus(A,B), 

C 

)  plus(A,B,C) . 

equal(  power_eval(A , 8) , 

C 

)  power _eval(A,B,C) . 

equal (  prime(X) , 

and(not (zerop(X) ) , 

and(not (equal (X , addl (zero) ) ) , 
prime 1(X, deer (X)))) 

). 

equal (  priae_list(append(X,Y) ) , 

and(prime_liat(X) ,prime_list(Y)) 

). 

equal(  quotient (A , B) , 

C 

)  quotient (A, B ,C) . 
equal(  renainder(A ,B) , 

C 

)  remainder ( A, B, C) . 

equal(  reverse_(X) , 

reverse_loop(X ,  □  ) 

). 

equal(  reverse(append(A,B)) , 

append(reverse(B) ,reverse(A) ) 

). 

equal(  reverae_loop(A,B) , 

C 

)  reverae_loop(A ,B , C) . 

equal (  samefringe(X , Y) , 

equal (flatten(X) ,llatten(Y) ) 

). 

equal(  3igwa(zero, I) , 

quotient(times(I,addl(I)) ,2) 

). 

equal(  sort2(delet e (X ,L) ) , 
delete (X , sort 2 (L) ) 

). 

equal(  tautology _checker(X) , 

tautologyp(normalize(X) ,  □  ) 
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). 

equal (  timea(A,B), 

C 

)  times(A,B,C) . 

equal (  times_list(append(X ,Y) ) , 

times(timea_list(X) ,times_liat(Y) ) 

). 

equal(  value(normalize(X) , A) , 
valued,  A) 

). 

equal (  zerop(X) , 

or(equal(X,zero) ,not(numberp(X))) 

). 


diiierence(X,  X,  zero)  !. 
difference(plus(X ,Y) ,  X,  fix(Y))  !. 

difference(plus(Y,X) ,  X,  fix(Y))  !. 

difference(pluad.Y) ,  plua(X.Z),  diff  erence(Y.Z))  !. 

difference(plu3(B,plua(A,C)),  A,  plua(B,C))  !. 
diff erence(addl(plua(Y.Z) ) ,  Z,  addi(Y))  !. 
difference(addl(addl(X)) ,  2,  fix(X)). 


eq(plus(A,B) ,  zero,  and(zerop(A) ,zerop(B)))  !. 

eq(plus (A , B) ,  plua(A,C),  equalCf ix(B) ,fix(C) ) )  !. 

eq(zero,  differenced, Y)  ,not(leaap(Y,X)))  !. 
eqd,  diff erence(X.Y)  ,and(nuabarpd)  , 

and ( or ( equal d, zero)  , 

zerop(Y) ) ) ) )  !. 

eq(timea(X,Y) ,  zero,  or(zerop(X) ,zerop(Y) ) )  !. 

eq(appendd.B) ,  append(A.C),  equal (B,C))  !. 

eq(flattend)  ,  cona(Y,D),  and(nliatp(X)  ,  equal(X.Y)  )  )  !. 

eq(greateat_factor(X,Y) .zero,  and(or(zerop(Y) ,equal(Y, 1)) , 

equal(X,zero)))  !. 

eq(greateat_factord,_)  ,  1 ,  equald.l))  !. 

eq(Z,  times(W.Z) ,  and(nunberp(Z) , 

or(equal(Z,zero) , 

equal (W, 1) ) ) )  ! . 

eqd,  timesd.Y),  or(equal(X,zero)  , 

and(nuaberpd) ,  equal (Y ,  1) ))  )  !. 

eq(timea(A,B) ,  1,  and(not (equal (A, zero) ) , 

and(not(equal(B ,zero)) , 
and(numberp( A) , 

and(numberp(B) , 

and( equal (deer (A) .zero) , 

equal ( deer (B) .zero) ) ) ) ) ) 


)  !• 


eq(difference(X,Y) ,  diff erence(Z, Y) ,if(lessp(X,Y) , 

not(lessp(Y,Z) ) , 
if (lessp(Z , Y) , 

not(lessp(Y,X)) , 
equal(fix(X) ,fix(Z))))) 
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eq(lassp(X,Y) ,  Z,  if(lessp(X, Y) , 

equal(t.Z) , 
equal(f ,Z))) . 

sxpCI ,  plus(J.K),  times(exp(I,.I)  ,exp(I,K)))  !. 

exp(I ,  times(J.K),  exp(exp(I,J) .K)) . 

gcd(X,  Y,  gcd(Y.X))  !. 

gcd(times(X,Z) ,  times(Y.Z),  times(Z,gcd(X,Y))) • 
mylength(reverse(X) , length(X) ) . 

mylength( cons (_,cons(_,cons(_,cons(_, cons (_, cons (_,X7)))))) . 
%plua(6,length(X7)))  . 

laasp(remainder(_,Y) ,  Y,  aot(zerop(Y) ))  !. 

lassp(quotient(I, J) ,  I,  and(not(zerop(I)) , 

or(zerop( J) , 

aot(aqual( J , 1) ))) )  !. 

lessp(remainder(X,Y) ,  X,  and(not(zerop(Y)) , 

and(not (zerop(X) ) , 

not (lessp(X , Y) ) ) ) )  !. 

laaap(plas(X,Y) .  plua(X.Z),  lessp(Y.Z))  :•  !. 
leasp(timas(X,Z) ,  times(Y.Z),  and(aot(zarop(Z) ) , 

l«asp(X,Y)))  !. 

leasp(Y,  plua(X,Y).  aot(zarop(X)))  !. 
lessp(length(delete(X ,L) ) .  length(L) ,  member(X ,L) ) . 

meaning (plus _trea (append (X , Y) ) , A , 

plua(meaning(plus_tree(X) ,A) , 
meaning(plus_tree(Y) ,  A) ) 

)  !  . 

meaning (plus _tree (plus .fringe (X) ) , A , 
f ix(maaning(X,A) ) 

meaning (plus .tree (dalat a (X , Y) ) , A, 

if (member (X,Y) . 

diff erence(meaning(plus_tree(Y) ,A) , 

(  meaningd  ,  A) )  , 
meaning(plua_tree(Y) , A) ) ) . 

mymember(X,append(A,B) ,or(member(X,A) .member (X , B) ) )  !. 

mymember(X .reversed)  ,member(X,Y))  !. 

mymember(A , intersect (B , C) , and (member ( A , B ) .member (A , C) ) ) . 

nth(zero,_,zero) . 

nth(  □  . I , if (zerop(I) , [] .zero) ) . 

nth ( append ( A ,B) . I , append (nth ( A , I) ,nth(B , diff erence ( I , length ( A) ) ) ) ) . 

plus(plus(X,Y) , Z , 

plus (X , plus ( Y , Z) ) 

)  !• 
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plus(remainder(X,Y) , 

times (Y.quotient(X.Y)) , 
f ix(X) 

)  !• 

plus(X,addl(Y) , 

il (nuaberp(Y) , 

addl(plus(X,Y)), 
addl (X) ) 

). 

power_eval(big_plusl(L,I .Base) .Base, 
plus(power_eval(L,Base) ,1) 

)  !■ 

power_eval(power_rep(I .Base) .Base, 
lix(I) 

)  !  • 

power_eval(big_plus(X,Y,I .Base) .Base, 

plusCl ,plus(poser_eval(X,Base) , 
power  _  eval ( Y .Base))) 

)  :-  !. 

power _eval (big_plus (power _rep( I. Base) , 
power _rep( J , Base) , 
zero, 

Base) , 

Base , 
plus (I, J) 

). 

quotiant(plus(X,plus(X,Y)) ,2,plus(X,quotient(Y,2))) . 
quotient(times(Y,X) ,Y,if (zerop(Y) .zero.lix(X))) . 

remainder (_,  l.zero)  !. 

remainder (X ,  X.zero)  !. 

remainder(times(_,Z) ,  Z.zero)  !. 

remainder (times (Y,_) ,  Y.zero). 

reversa_loop(X,Y,  append(reverse(X) , Y)  ) 

reverse_loop(X,  □  ,  reverse(X)  ). 


times(X,  plus(Y.Z),  plus(times(X, Y) .times(X.Z))  ) 

times(tiaes(X,Y) ,Z,  times (X , times (Y ,Z) )  ) 

times(X,  diiierence(C.W) ,  diiierence(times(C ,X) .times(W.X))  ) 

times (X,  addl(Y),  if (numberp(Y) , 

plus(X , times (X , Y) ) , 

fix(X))  )• 
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4.  Prolog  Browse 


'/,/*  Copyright  Herve’  Touati,  Aquarius  Pro j set,  UC  Berkeley  */ 

’/,/*  obtained  irom  Tep  Dobry  */ 

'/,/*  modified  by  Herve’  Touati  01/15/87  */ 

main  statistics, 

init( 100, 10,4, 

CCa,a,a,b,b,b,b,a,a,a,a,a,b,b,a,a,a], 

[a,a,b,b,b,b,a,a, [a, a] , [b,b]] , 

[a ,  a ,  a ,  b ,  [b ,  a]  ,  b ,  a ,  b ,  a] 

]. 

Symbols) , 

randomize (Symbols .RSymbols ,21) , ! , 
investigate(RS ymbols , 

[[star(SA) ,B, star (SB) ,B ,a,star(SA) , a, star (SB) ,star(SA)] , 
[star(SA) ,star(SB) ,star(SB) ,star(SA) , [star(SA)] , [star(SB)]] , 
C_,_,atar(_) , [b,a] ,star(_) ,_, J 
]). 

statistics. 

init(I,M,Ipats,Ipats, Result)  init(I, K.H.Hpats.Ipats, Result) . 

init(0,_, !. 
init(H,I,M,Ipats,Ipats, [SymblRest]) 
filld.D  ,L). 

get_pats(Hpats .Ipats .Ppats) , 

J  is  II  -  I, 

fill(J, [pattern(Ppats) IL] ,Symb) , 

II  is  I  -  1, 

(I  ==  0  ->  II  is  H;  II  is  I  -  1). 
initdl, II, M, Ipats, Ipats, Rest) . 

f ill(0 ,L,L)  ! . 

f ill (I ,L, [dummy(  □  ) I  Rest] )  HI  is  I  -  1,  f ill(Sl ,L,Rest) . 


randomize (  □  ,  □  ,_)  !. 

randomize(In, [XlOut] ,Rand) 
length(In.Lin) , 

Randl  is  (Rand  *  17)  mod  251, 
H  is  Randl  mod  Lin, 
split(N , In,X , Ini) , 
randomize (Ini ,0ut .Randl) . 

split (0 ,  [X I Xs] , X , Xs)  : -  ! . 
split ( H, [XI Xs] , RemovedElt ,  [X I Ys] ) 
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SI  is  I  -  1, 

split(Sl ,Xs , RemovedElt ,Ys) . 


investigate^  ,_) . 
investigate( [UlUnits] .Patterns) 

property(U, pattern, Data) , 
p_investigate(Data, Patterns) , 
investigate(Units .Patterns) . 


get _pats (Spats , Ipats , Result)  get .pats (Spats , Ipats .Result , Ipats) . 

get_pats(0,_,  □  ,_)  !. 

get_pats(S, [XlXs] , [XI Ys] .Ipats) 

SI  is  I  -  1, 

get _pats(81 ,Xs , Ys , Ipats) . 
get_pats(S,  □  ,Ys, Ipats)  : - 

get _pats(S, Ipats ,Ys . Ipats) . 

property(  □  ,_,_)  iail.  /*  don’t  really  need  this  */ 
property([ProplRProps] ,P,Val) 
iunctor(Prop,P,_) . ! , 
arg(l.Prop.Val) . 
property ( [_ I RProps] , P , Val )  : - 

property(RProps,P , Val) . 

p_investigate(  □  . _) . 
p_investigate( [D iData] .Patterns) 
p_match(Patteras  ,D) , 
p_investigate(Data, Patterns) . 

p_match(  □  , _) . 
p_match( [P I  Patterns] ,D) 

(match(D.P),  fail;  true), 
p_match(Patterns ,  D) . 

match(  □  .  □  )  ! . 

match( [XI PRest] , [Yl SRest] ) 
var(Y) , ! ,X  =  Y, 
match(PRest .SRest) . 
match(List , [Yl Rest] ) 

nonvar(Y) ,Y  =  star(X),!, 
concat(X, SRest, List) , 
match(SRest .Rest) . 
match( [X I PRest] ,  [Yl SRest] ) 

(atom(X)  ->  X  =  Y ;  matoh(X.Y)), 
match(PRest .SRest) . 

concat (  □  , L , L) . 

concat ( [X  I  LI] ,L2 , [XI L3] )  concat(Ll ,L2,L3) . 
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5.  Prolog  Frpoly 


"FRPOLY"  symbolic  polynomial  powering  algorithm. 
Converted  from  Lisp  (Gabriel  Suite)  by  Rick  McGeer. 

To  run,  say 

?-setup. 

?-bench(5) . 

?-bench(10) . 

?-bench(!S) . 


main  statistics(runtime,_) , 
setup, 

statistics(runtime ,  [_,A] ) , 
bench (S ) , 

statistics (runtime,  [_,B] ) , 
bench(lO) , 

statistics(runtime, [_,C] ) , 
bench(lS) , 

statistics(runtime , [_,D] ) , 

write(A),  nl, 

write(B) ,  nl, 

write(C) ,  nl, 

write(D) ,  nl. 


'/.  Polynomial  addition 

poly_add(  poly(Var,  Termsl),  poly(Var,  Terms2) ,  poly(Var,  Terms3)  ) 
! 

add_t erms (Terms  1 ,  Terms2,  Terms3) . 


poly_add(  poly(Varl,  Termsl),  poly(Var2,  Terms2) ,  poly(Varl,  Terms3)  ) 
V ax 2  «>  Varl, 

I 

add_To_Zero_Term(Terms 1 ,  poly(Var2,  Terms2) ,  Terms3  ). 

poly_add(  poly(Varl,  Termsl),  poly(Var2,  Terms2),  poly(Var2,  Terms3)  ) 
Varl  <B>  Var2, 

i 

•  l 

add_To_Zero_Term(Terms2 ,  poly(Varl,  Termsl),  Terms3  ). 


7.7. 

•/. 

•/. 

*/. 

7. 

7. 

7. 

7. 

7. 

7.7. 
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poly_add(  poly(Varl,  Taras  1),  H,  poly(Varl,  Terms3)) 

I 

•  I 

add_To_Zero_Term(Termsl ,  H,  Terms3  ). 


poly_add(  H,  poly(Vax2,  Terms2) ,  poly(Var2,  Teras3)) 

i 

•  f 

add_To_Zero_Tera(Terms2 ,  H,  Taras3  ). 


'/,  Straight  addition  oi  numbers 

poly_add(H,  M,  T) 

T  is  I  +  M. 

*/.  adding  Terms 

add_tarms( □  ,X,X)  !. 

add _t arms (X,  □  tX)  !. 

add_terms( [tarm(Exp.Cl) iTarasl] , [tara(Exp,C2) ITeras2] , [term(Exp.C) ITerms]) 
•  » 

poly_add(Cl ,  C2 ,  C) , 

add.terms (Terms  1 ,  Taras2,  Terms). 

add_terms( [term(El.Cl) ITarasl] , [tara(E2,C2) |Teras2] , [term(El ,C1) ITerms] ) 

El  <  E2, 

i 

•  » 

add  .terms  (Terms  1 Ctara(E2,C2)  lTeras2]  .Terms) .  | 

add.terms (Terms  1 ,  Ctexm(E2,C2)  lTerms2]  ,  [term(E2,C2)  ITerms]) 
add.terms (Terms  1 ,  Terms2,  Terms). 

add_To_Zero_Term( [tera(0 ,C1) ITerms] ,C2, Ctarm(O.C) ITerms]) 

i 

•  » 

poly_add(Cl ,  C2,  C). 

add_To_Zaro_Term(Terms ,C , [term(0 ,C) ITerms] ) . 

i 

’/,  Polynomial  Multiplication 

poly_mult(poly(Var,  Termsl),  poly(Var,  Terms2) ,  poly(Var,  Terms3)) 
form_poly_product (Terms  1 ,  Terms2,  Terms3) . 

poly_mult.(  poly(Varl,  Termsl),  poly(Var2,  Terms2) ,  poly(Varl,  Terms3)  ) 
Var2  «>  Varl , 

| 

multiply_through(Termsl ,  poly(Var2,  Terms2),  Terms3  ). 
poly_mult(  Polyl,  poly(  Vax2,  Terms2),  poly(Var2,  Terms3)  ) 

i 
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multiply_through(Terms2,  Polyl,  Terms3  ). 
poly_mult(  poly(  Var2,  Terms2) .  Polyl,  poly(Var2,  Ter»s3)  ) 

i 

■  » 

mult iply .through (Terms 2 ,  Polyl,  Terms3  ). 

poly_mult(Cl ,  C2,  C) 

C  is  Cl  *  C2. 

mult iply _through(  □  ,  □)  !. 

multiply_through( [tarm(H.Tl) ITerms] ,  Poly,  [term(H.HewTl) iNeuTerms] ) 
poly_mult(Tl ,  Poly,  HasTl), 
multiply_through(Terms ,  Poly,  NesTerms). 

f  orm.poly  .product  (□,_,□  )  !. 

lonn_poly_product(_,  □  .  □  )  !. 

Torm_poly_product( [Tl ITerms] ,  Tarms2,  Tarms3) 
iorm_single_product(Terms2,  Tl,  Ta) , 
iorm.poly.product (Terms ,  Terms2,  Tb) , 
add_terms(Ta,  Tb,  Terms3) . 

iorm.single.product  (□,_,□  )  !. 

form_single_product( [term(Expl ,C1) ITarms] ,  tarm(Exp2 ,C2) ,  [tarm(Exp.C) iProducts]) 
Exp  is  Expl  +  Exp2, 
poly_mult(Cl ,  C2,  C) , 

iorm_singla_product(Tarms ,  tarm(Exp2,C2) ,  Products). 

'/,  Polynomial  Exponentiation 

poly.axpt (0 ,  _,  1)  !. 

poly_expt(H,  P,  Result) 
evenP(H) , 

!  .  1 
M  is  H  //  2, 

poly_expt(M ,  P,  HextRas), 
poly_mult(HextRes ,  HextRes,  Result). 

poly_expt(H,  P,  Result) 

M  is  H  -  1, 

poly_expt(M,  P,  HextRes), 
poly_mult(P,  HextRes,  Result). 


'/.poly_expt(H,  P,  Result) 

'/,  poly_expt(  H,  P,  1,  Result). 
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7.poly_expt(0,  Result,  Result)  !. 

7. 

7.poly_expt(H ,  P,  ResSoFar,  Result) 

'/,  evenP(N), 

*/. 

7.  M  is  H  //  2, 

7,  poly .mult (ResSoFar,  ResSoFar,  HeztRes), 
'/,  poly_expt(M,  P,  HeztRes,  Result). 

7. 

7.poly_expt(H,  P,  ResSoFar,  Result) 

7.  M  is  I  -  1, 

7.  poly_ault(P,  ResSoFar,  HeztRes), 

I,  poly_expt(M,  P,  HeztRes,  Result). 

7. 


setup 

poly_add(poly(y , [tara(O.l) ,term(l,l)]) ,poly(z, [term(l,l)]) ,Tmp) , 
poly_add(poly(x, [tara(l . 1)] ) ,Tap,R) , 
assert(test_case(R)) . 

evenP(X)  : - 

H  is  X  //  2, 

X  is  H  *  2. 


print _poly (poly (Vax,  Teras)) 

i 

•  » 

print_Terms (Teras ,  Var) . 

print _poly(X) 
write(X) . 


print_Teras(  □  ,_)  !. 

print _Terms( [tera(_,  0) I  Terms] , Var) 

i 

•  » 

print .Terms (Teras ,  Var). 
print .Terms ( [Term] , Var) 

I 

•  » 

print _Term(Term,  Var) . 

print _Terms( [TermlTerms] , Var)  : - 
print .Term (Term,  Var) , 
arite( '  +  ’ ) , 
print .Terms (Terms ,  Var). 

print _Term(term(0 ,  P) ,  _)  : - 

i 
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print _poly(P) . 

print _Term(tenn( 1 ,  C) ,  Var) 

print _Coef£ (C) , 
srrite(Var) . 

print _Term(tarTn(Exp,C) ,  Var)  : - 
print _Coafi (C) , 
srita(Var) , 
srita( ' *  ’ )  ■ 
writa(Exp) . 

print_Coe£f (1)  !. 

print  _Coa££  (If) 
atonic(S) , 

i 

» 

sritad) , 

srita( ’*’) • 
print_Coa£l(P) 

i 

•  » 

writa( ’ ( ’) , 
print _poly(P) , 
writa( ’ ) ') , 

»rita( ’*') . 

banch(I) 

tast_caaa(X) , 
poly_axpt(I,  X,  Y) . 


30 


6. a.  Prolog  Prover 


% 

•/. 

*/. 

•/. 

•/:/. 


Prolog  theorem  prover  to  be  compared  against  Lisp 
(R.A.  O’Keefe  -  "Prolog  Compared  with  Lisp?") 

(from  Sigplan  notices,  vol  18  #5,  May  1983) 


•/.*/. 

7. 

*/. 

7. 

•/. 

•/:/. 


•mm:/:/. 
'  7:av:/:m 

•/:/:/:/:/:/:/:/. 


Also  to  be  mn  with  suppressed  output,  for 
computation  time  only 


/:/:/:/:/:/:/:/ 


•i:/:/:/:/:/:/:/. 


i:/:/:i:/:/:/:i 

•/:/:/:/:/:/:/:/ 


main  statistics (runtime , _) , 
timed( 10 , 10) , 

statistics (runtime , [_, A] ) , 
timed(10,9) , 

statistics(runtime, [_,8]), 
timed(10,8) , 

statistics(runtime , C_,C] ) , 
timed(10,7) , 

statistics (runtime, [_,D]), 
timed(10,6) , 

statistics(runtime , [_,E] ) , 
timed(10 ,5) , 

' 3tati3tics(runtime , [_,F] ) , 
timed( 10,4), 

statistics (runtime , [_,G] ) , 
timed(10,3) , 

statistics (runtime , (_ ,H] ) , 
timed(10,2) , 

statistics(runtime , [_, I] ) , 
timed( 10,1), 

statistics(runtime , [_, J] ) , 
, write(A) ,  nl, 
write(B) ,  nl , 
write(C),  nl, 
write(D) ,  nl, 
write(E) ,  nl , 
write(F) ,  nl, 
orite(G) ,  nl, 
srite(H),  nl , 
write(I) ,  nl , 
orite(J),  nl. 


public 

go/1 , 


7.  quick  test  using  stored  problems 
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implies/2, 
timed/ 2 . 


'/.  the  provar  propar 
'/.  ior  getting  CPU  times 


: -  mode 

add_conjunction(+,+,+) , 
expand(+,+,-) , 
ext and (+,+,+, -,+,-) , 
go(+) , 

implies (♦,+) , 
includes (+,+) , 
opposite(+,-) , 
problem(+,-,-) , 
reiute(+) , 
try(+) , 
tiaed(+ , +) . 

op(950 ,  xiy,  #). 
op(850 ,  xiy,  A). 

: -  op (500 ,  ix,  +) . 
op (500 ,  ix,  -). 

implies (Premise,  Conclusion) 

writa( ’Trying  to  prove  that  ’),  write(Premise) , 
writa(’  implies  ’),  write(Conclusion) ,  nl, 
opposite(Conclusion,  Denial),  !, 

add_conjunction(Premise,  Denial,  is (□,□,□,□)). 

opposita(F0  *  GO,  FI  #  Gl) 

opposite(F0,  FI),  !, 
opposite(G0,  Gl)  . 
opposite(Fl  #  Gl,  FO  A  GO) 

opposite(Fl,  FO) ,  !, 
opposite(Gl,  GO). 
opposite(+Atom,  -Atom). 
opposite(-Atom,  +Atom) . 

add_conjunction(F,  G,  Set):- 
l  write( ’ Expanding  conjunction  ’),  write(F  A  G) , 

write(’  by  Rule  1’),  nl, 
expand(F,  Set,  Mid), 
expand(G,  Mid,  Hew),  !, 
reiute(Hew) . 

expand (Formula,  reiuted,  refuted) . 

expand(F  A  G,  fs(D,C,P,H),  refuted)  includes(D,  FAG),  !. 
expand(F  A  G,  is(D,C,P,H),  fs(D,C,P,H))  includes(C,  F  A  G) , 
expand(F  A  G,  fs(D,C,P,N),  New) 

expand (F,  f s(D ,  [FAG  I C] , P ,N) ,  Mid),  !, 
expand(G,  Mid,  New). 
expand(F  #  G,  is(D,C,P,N),  Set) 

opposite(F  #  G,  Conj),  !, 


7.  disjunction 
%  conjunction 
'/.  assertion 
'/.  denial 
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extend(Conj ,  D,  C,  Dl,  f s(Dl , C,P,S) ,  Set). 
expand(+Atoa,  fs(D,C,P,S),  Set)  !, 

extend(Atom,  P,  B,  PI,  ls(D,C,Pl ,H) ,  Set), 
expand (-Atom,  fs(D,C,P,H),  Set)  !, 

ext end( Atom,  S,  P,  SI,  f s(D ,C  ,P ,H1) ,  Set). 

includes( [HeadITail] ,  Head)  !. 

includes( [HeadITail] ,  This)  includes (Tail ,  This). 

ext end (Exp ,  Pos,  Seg,  Be»,  Set,  refuted)  includesOleg,  Exp), 
extend(Exp,  Pos,  Seg,  Pos,  Set,  Set)  includes(Pos ,  Exp),  !. 
extend(Exp,  Pos,  Seg,  [Exp I Pos],  Set,  Set). 

«. 

refute(refuted)  srite( 'Contradiction  spotted  (Rule  3).’),  nl. 
refute(fs( [FI  *  GlID],  C,  P,  S)) 
opposite(Fl,  FO) , 
opposite(Gl,  GO), 

Set  =  fs(D,  C,  P,  S), 

write(’Case  analysis  on  ’),  urite(F0  #  GO), 
writeC  using  Rule  2’),  nl, 
add_conjunction(FO ,  Gl,  Set), 
add_conjunction(FO,  GO,  Set), 
add_conjunction(Fl ,  GO,  Set). 
refute(Set) 

write(’Can”t  refute  ’),  urite(Set),  nl. 


problem(  1,  -a,  +a) .  , 

problem(  2,  +a,  -a  *  -a). 

problem(  3,  -a,  +to_be  #  -to_be) . 

problem(  4,  -a  k  -a,  -a). 

problem(  5,  -a,  +b  #  -a). 

problem(  6,  -a  k  -b,  -b  k  -a). 

problem(  7,  -a,  -b  t  (+b  k  -a)). 

problem(  8,  -a  #  (-b  #  +c)  ,  -b  #  (-a  s*  +c)). 

problem(  9,  -a  #  +b,  (+b  k  -c)  #  (-a  #  +c)). 

problem(  10,  (-a  #  +c)  S  (-b  #  +c)  ,  (-a  k  -b)  tt  +c). 


try(N)  problem(H,  P,  C),  !, 
implies(P,  C). 
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i 


timed(0 ,  _)  ! . 

timed (K ,  8)  (try(H);  true),  J  is  K-l,  !,  timed(J.H), 


\ 
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6.b.  Lisp  Prover 


Lisp  theorem  prover  to  be  compared  against  Prolog 
(R.A.  O’Keefe  -  "Prolog  Compared  oith  Lisp?") 

(from  Sigplan  Kotices,  vol  IS  #5,  May  1983) 
<FranzLisp  Version> 

<corrected> 


Also  to  be  run  with  suppressed  output,  for 
computation  time  only 


(defmacro  time  (z) 

‘ (prog  (X  Y) 

(setq  X  (ptime)) 

.2 

(setq  Y  (ptime)) 

(princ  (cons  (-  (car  Y)  (car  X)) 

(-  (cadr  Y)  (cadr  X)))) 

(terpri))) 


(declare 

(special  Cases  D  C  P  H  Refuted)) 

(defun  implies  (Premise  Conclusion) 

(princ  (list  "Trying  to  prove  that”  Premise  "implies"  Conclusion)) 
(terpri) 

(add-conjunction  Premise  (opposite  Conclusion)  nil  nil  nil  nil) 

) 

(defun  opposite  (F) 

(prog  (0) 

(setq  0  (car  F)) 

(return  (cond  ((eq  0  ’\t) 

(cons  ’\#  (cons  (opposite  (cadr  F)) 

(opposite  (cddr  F))  ))) 

((eq  0  *\#) 

(cons  ’ \4  (cons  (opposite  (cadr  F)) 

(opposite  (cddr  F))  ))) 

((eq  0  ’+) 

(cons  (cdr  F))) 

((eq  0  ’-) 

(cons  '+  (cdr  F))) 
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(defun  add-conjunction  (F  G  D  C  P  8) 

(prog  (Refuted) 

(princ  (list  "Expanding  conjunction"  (cons  ’\t  (cons  F  G)) 

"by  Rule  1"))  (terpri) 

(setq  Refuted  nil) 

(expand  F) 

(expand  G) 

(cond  (Refuted 

(princ  "Contradiction  spotted") (terpri) 

(return  t)) 

((not  (atom  D)) 

(return  (split  (cadar  D)  (cddar  D)  (cdr  D))  )) 

(t 

(princ  (list  "Can’t  refute"  D  C  P  >)) (terpri) 

(return  nil)) 


(defun  split  (FI  G1  D) 

(prog  (F  G) 

(princ  (list  "Case  analysis  on"  (cons  '\#  (cons  FI  Gl)) 

"(Rule  2)")) (terpri) 

(setq  F  (opposite  FI)) 

(setq  G  (opposite  Gl)) 

(return  (and  (add- conjunct ion  F  Gl  D  C  P  I) 
(add-conjunction  F  G  D  C  P  I) 
(add-conjunction  FI  G  D  C  P  S) 


(defun  expand  (F) 
(prog  (0) 


(setq  0  (car  F)) 

(cond  ((eq  0  ' \* ) 

(cond  ((member  F  D)  (setq  Refuted  t)) 

((member  F  C)  nil) 

(t  (setq  C  (cons  F  C)) 

(expand  (cadr  F)) 

(expand  (cddr  F))  ))  ) 

((eq  0  ’\#}  (setq  D  (extend  (opposite  F)  D  C))  ) 
((eq  0  '+)  (setq  P  (extend  (cdr  F)  P  H))  ) 

((eq  0  ’-)  (setq  S  (extend  (cdr  F)  S  P))  ) 


(defun  extend  (F  A  B) 

(cond  ((member  F  B)  (setq  Refuted  t)  A) 
((member  F  A)  A) 
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) 


(t  (coas  FA)) 


(defun  try  (M) 

(implies  (vref  Cases  (*  2  M)) 

(vref  Cases  (1+  (*  2  M))))) 


(defun  setup  () 

(setq  Cases  (vector 


’(-  . 

a) 

'(+  . 

.  a) 

’(+  . 

b) 

’(\* 

(-  . 

b)  . 

(-  • 

b)) 

'(-  . 

nothing) 

*(\# 

(+  • 

to-be)  . 

(-  ■ 

’(\A 

(-  • 

a)  ( 

-  ■  a)) 

’(-  ■ 

a) 

’(-  • 

b) 

’(\# 

(+  . 

a)  . 

(-  . 

b)) 

’(\A 

(-  - 

a)  . 

(-  •  b)) 

’(\* 

(-  • 

b)  . 

(-  • 

a)) 

’(-  . 

b) 

'(\#  (-  . 

a)  . 

.  (\* 

(+  . 

a)  . 

(- 

'  (\# 

(-  • 

a)  . 

(\#  (-  . 

b)  . 

(+  . 

c))) 

'(\#  (-  . 

.  b)  . 

.  (\# 

(-  • 

a)  . 

(  + 

’(\# 

(-  • 

a)  . 

(+  .  b)) 
’(\#  (\* 

(+  . 

b)  . 

(-  . 

c)) 

(\# 

(-  . 

a)  . 

(+  . 

c))) 

'(\* 

(\# 

(-  . 

a)  .  (♦  . 

c)> 

.  (\# 

(-  . 

b)  . 

(  + 

'(\#  (\* 

(-  . 

a)  . 

(-  . 

b)) 

.  (+ 

(defun  timed  (K  M) 

(prog  () 

L  (try  M) 

(cond  ((greaterp  (setq  K  (subi  K))  0)  (go  L))) 

)) 


(defun  doit  () 


(setup) 

(time 

(timed 

10 

9)) 

(time 

(timed 

10 

3)) 

(time 

(timed 

10 

7)) 

(time 

(timed 

10 

6)) 

(time 

(timed 

10 

S)) 

(time 

(timed 

10 

4)) 

(time 

(timed 

10 

3)) 

(time 

(timed 

10 

2)) 

(time 

(timed 

10 

D) 

(time 

(timed 

10 

0))) 

to-be) ) 

.  b))) 

.  c))) 

.  c))) 

.  O) 
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7.  Prolog  Puzzle 


/*  Copyright  Herve’  Touati,  Aquarius  Project,  UC  Berkeley  */ 

main  statistics(nintime , _) , 
make _board( Board) , 
initialize (Board,  Pieces), 
statistics(runtime, C_,A] ) , 
play (Board,  Pieces,  Board), 
statistics(runtime, C_,8] ) , 
write(A) ,  nl, 
write(B) ,  nl. 

initialize ( [Spot  I _] , [[b, c ,d,e ,i ,g,h, i, j ,k,l,m] , [n,o ,p] , [q]  , [r]] )  : 
set(0,0) , 
pl(a,Spot) . 

play(  □  ,_, Board) 

access(O.H) , 

*rrite( ’Success  in  *), 
write(I) , 

writeC  trials.’),  nl. 

play( [s(V, _,_,_) iRest] .Pieces .Board) 
nonvar(V) ,  ! , 
play(Rest, Pieces, Board) . 

play( [Spot  I  Rest] .Pieces .Board) 

iill(Spot .Pieces .RewPieces) , 
incr, 

play (Rest .ResPieces .Board) . 


incr  : - 

access(0,  Count), 

ICount  is  Count  +  1 , 

'/,  write(Count)  ,  nl, 

set(0,  KCount). 

fill(Spot,  [[MarklPl]  IT]  ,  [PUT])  pl(Mark.Spot).. 

JilKSpot,  [PI.  [MarklP2]  IT]  .  [P1.P2IT])  p2(Mark,Spot)  . 
fill(Spot, [P1.P2, CMarklP3] IT] , CP1.P2.P3IT])  p3 (Mark, Spot ) . 
f ill(Spot , [PI ,P2 ,P3 , [Markl P4] IT] . [PI ,P2 , P3 ,P4 IT] )  p4(Mark,Spot) 

'/.  4-2-1 

pl(M,s(M,s(M,s(M,s(M,_,C13,_) ,C12,_) ,CU,_) ,s(M,Cll _ ) ,_)) 

C13  =  s  (M - ,_), 

C12  =  s (M , C13 , _ , _) . 

Cll  =  s(M,C12,_,_) . 

'/.  2-1-4 

pl(M, s(M, s(M, Cll), _,s(M, Cll, _,3(M,C12,_,s(M,C13, _,_))))) 
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C13  =  a(M, 

C12  =  s(M,_,_.C13) , 

Cll  =  a(H,_,_,C12) . 

•/.1-4-2 

pl(M,a(M,_,a(M,_,3(M,.,a(M,_,_,C13) ,C12),Cll),a(M,_,Cll,_)))  :- 
C13  =  a(M, 

C12  =  a (M ,_ , C13 , _) , . 

Cll  =  s(M,_,C12, J . 

7.  2-4-1 

pl(M,s(M,s(M,_.Cll._).s(M,Cll,s(M,C12.sCM.C13. :- 
C13  =  s(M, 

C12  =  s(H,_,C13,_) , 

Cll  =  s(M,_,C12, J .  » 

7.  4-1-2 

pl(M,s(M,s(M,s(M,s(M,_._,C13) ,_,C12) Cll), _,s(M, Cll, _,_)))  :- 
C13  =  s(M, , 

C12  =  «(M,C13,_,_) , 

Cll  =  s(M,C12,_,_) . 

7. 1-2-4 

pl(M, s(M, a (M, Cll), s(M,_, Cll, s(M,_,C12,s(M,_,C13, _)))))  :- 
C13  =  s(M, 

C12  =  s(M,_,_,C13) , 

Cll  =  a(M,_,_,C12) . 

p2(M,a<!!.s(M,s(H, _ )). 

p2 (M, a (M, _, a (M, _, a (M, . 
p2 (M,s(M, a (M, a (M, 

p3(M1a(M,s(M,_,C. J,a(M,C, :-  | 

C  =  a(M, 

p3(M,a(M,s(M,_,_,C) a (M.C, _,_)))  :- 
C  =  a(M, 

p3(M,a(M,_,a(M,_,_,C),a(M,_,C,_)))  :- 
C  =  a(M, . 

p4(M, a (M, a(M, _, C110, C101),a(M, C110,., s(M, Clll, a(M,C101, C011 ,_))) 

Clio  =  a(M _ ,C111), 

C101  =  a(M, _,C111 ,_) , 

COU  =  a(M,Clll _ ). 

Clll  =  s(M, . 

tnaia.boardCLevelO)  : - 

aaJta.lavaKLavalO-Lavall  ,Levell-_)  , 
ma£e_lavel(Levell-Level2 ,Level2-_) , 
maXe_lavel(Laval2-Level3 ,Level3-_) , 
malce_level(Level3-Level4 ,Level4-_) , 
m5Lke_lavel(Laval4-  □  ,X-  []  )  , 

X  =  [z,z,z,z,z,  z.z.z.z.z,  z,z,z,z,z,  z.z.z.z.z,  z,z,z,z,z]. 


mcLka_level(C-Lini,Z-L)  :  - 

C  =  [COO , CIO , C20 , C30 , C40 , 
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C01.C11, C21.C31.C41, 

C02 , C 12 , C22 , C32 , C42 , 

C03 , C13 , C23 ,C33 , C43 , 

C04 , C 14 , C24 , C34 , C44 I  Link] . 
Z  =  [200,210,220,230,240, 

Z01 ,Z11 ,Z21 ,Z31 ,Z41 , 

Z02 , Z12 , Z22 , Z32 , Z42 , 

203, Z13, 223, 233, 243, 

Z04 , Z14, Z24 , Z34 , Z44 I L] , 

COO  =  a(_,C10,C01,ZOO), 

CIO  =  s(_,C20,Cll,Z10) , 

C20  =  s(_,C30 ,C21 , Z20) , 

C30  =  s(_,C40,C31, 230 ) , 

C40  =  s(_,  z,C41,240), 

C01  =  s(_,Cll,C02,Z01) , 

Cll  *  s(_,C21 ,C12,211) , 

C21  =  s(_,C31,C22,221) , 

C31  =  s(_,C41 ,C32,Z31) , 

C41  a  s(_,  Z.C42.241), 

C02  =  s(_,C12,C03,Z02) , 

C12  =  s(_,C22,C13,Z12) , 

C22  =  a ( _ , C32 , C23 , Z22 ) , 

C32  =  s ( _ , C42 , C33 , Z32 ) , 

C42  a  s(_,  z,C43,Z42) , 

C03  a  a(_,C13,C04,Z03) , 

C13  =  s (_ ,C23 ,C14 , Z13) , 

C23  =  a ( _ , C33 , C24 , Z23 ) , 

C33  =  s ( _ , C43 , C34 , Z33 ) , 

C43  a  s(_,  2.C44.Z43), 

C04  =  s(_,C14,  z,Z04), 

C14  =  s(_,C24,  z,214)  , 

C24  =  s (_,C34 ,  z,Z24) , 

C34  =  s(_,C44,  z , Z34) , 

C44  =  s(_,  z,  z,Z44) . 


'/,  set  and  access  lor  systems  that  don't  support  them 
dynamic  ’$set'/2. 

set(S,  A)  (retract (' $set  ’  (M ,  _) ) ;  true),  assert (’ $set ’ (H ,  A)), 
access(S,  A)  '$set’(M,A),  !. 
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